home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
rmail181.zip
/
RBBSMAIL.DOC
< prev
next >
Wrap
Text File
|
1992-02-28
|
98KB
|
2,639 lines
RBBSMail, the RBBS-PC Echomail Processor
Version 18.1
(C) by Jan R. Terpstra
Februari 28, 1992
Bamestra RBBS
P.O.Box 66
1462 ZH Beemster
The Netherlands
RBBSNet 8:998/1.0
FIDONET 2:512/10.0
phone1 ++31 2998 3602 (v24)
phone2 ++31 2998 3603 (HST)
Document Number RM_920228
RBBSMail v18.1
│ Revisions in this document are marked by a sidebar like the one on the
│ left of this sentence.
NOTICE: This is NOT a drop-in replacement of RBBSMAIL.EXE, you need to
change the configuration and batch files before running this version of
RBBSMail!!!!!!!
RBBSMail v18.1
1. WARNING!
Please note that RBBSMail v18.x is *NOT* a drop-in replacement for earlier
versions of RBBSMail. Several configuration phrases and command line
switches have changed. You *MUST* make changes to RBBSMAIL.CFG and to
your batchfiles invoking RBBSMail to prevent sending out messages that may
not confirm to current FIDONET echomail distribution standards.
What you should do before installing and running this version of
RBBSMail.
■ Delete all .EID files from your system. RBBSMail v18 uses a new
method of checking for duplicates.
■ In the directory where you run RBBSMail, type the command
ATTRIB RBBSMAIL.NUM -S -H (DOS 5.0) and delete the file RBBSMAIL.NUM.
■ Read this document and make the required changes to your RBBSMAIL.CFG
and AREA.BBS files.
■ Note that the command line switches of RBBSMail have changed. Earlier
versions used a colon ":" as command delimiter. RBBSMail v18 uses a
space between command line switch and parameter.
■ Type RBBSMAIL with the appropriate command line switches and cross you
fingers.
WARNING! 1
RBBSMail v18.1
2. What is RBBSMail
RBBSMail is a program that allows sysops of RBBS-PC bulletin boards to
hook their bulletin board into the international FIDONET and participate
in Echomail. The combination RBBS-PC + RBBSMail + any of the mail
frontends will process messages entered in designated conferences of the
RBBS-PC system and send those messages to any other system in the
FIDONET. It will put received Echomail in the proper RBBS-PC MESSAGES
file or in to FIDO style message subdirectory.
This way, RBBS-PC conferences can be shared among multiple RBBS-PC and
other systems in the FIDONET. Messages entered on any of the bulletin
boards in an Echomail net will eventually be copied over to all the other
bulletin board systems connected to the net. RBBSMail does handle
reception of directly addressed FIDONET messages but it cannot handle
explicitly addressed messages from users on your system simply because
RBBS-PC does not (yet??) provide a way of addressing network messages.
RBBSMail can only process Echomail.
To accomodate bulletin board systems that run another BBS program next to
RBBS-PC, RBBSMail can also do Import and Export functions on FIDO style
message subdirectories, just like ConfMail, QM and Dutchie's Conference
manager do. This allows a mixed environment where both RBBS-PC and a FIDO
compatible BBS program can participate in Echomail on a single computer.
2.1 Software Requirements
To run RBBSMail, you need (of course) a working RBBS-PC based bulletin
board with a version of RBBS-PC that will run with a frontend mailer
(RBBS-PC v16.1A or later), RBBSMail and suitable batch files. RBBSMail
can handle RBBS-PC MESSAGES files produced by RBBS-PC v16.1A and higher.
RBBSMail will work happily with any FTS-0001 compatible front-end mailer,
like BinkleyTerm, FrontDoor, Dutchie or SEAdog. All programs have strong
and week points, it is up to you to decide which one to use.
BinkleyTerm is distributed including the C sourcecode, just like RBBS-PC.
This makes the two programs "live with the same spirit". The combination
of BinkleyTerm, RBBSMail and the FIDO compatible message editor MsgEd
(sourcecode also available) is my personal preference.
Dutchie is a FIDO compatible mailer of Dutch origin (hence the name).
Dutchie's older version came excellent documentation, containing a very
educational section on FIDONET basics. Sadly enough, the current level of
Dutchie's documentation is "less usefull" (pun intended).
FrontDoor is a commercial FIDO compatible mailer of good quality. It has
a been a stable product for quite some time and exploits some interesting
extras.
SEAdog was the first commercial FIDONET compatible mailer. While a bit
What is RBBSMail 2
RBBSMail v18.1
limited in functionality, it has been a reliable and stable product for a
long time.
D'Bridge is a commercial FIDONET mailer including echomail handling,
message editor, maintenance and a handful of other utilities. While
D'Bridge looks like a nice package at first glance, it has had a long
lasting history of being bug-infested, badly supported and not really
compliant with current FIDONET standards.
When using all of RBBSMail's ARCmail abilities, you must have copies of
the programs ARCA.COM, ARJ.EXE, PAK.EXE, LHA.EXE, PKZIP.EXE, PKUNZIP.EXE,
ZOO.EXE and GUS.EXE, either in the current subdirectory or in a
subdirectory listed in your DOS PATH environment variable.
2.2 Hardware Requirements
The minimum hardware requirements to run RBBSMail are the same as those
for RBBS-PC (think about that for a while....)
2.3 Limitations.
I hate to leave people out in the blue as to what they can and cannot do
with this program. To my opinion, if a program has limitations or
restrictions, they should be documented. Here are the most important
limititations of RBBSMail:
■ The main code and data of RBBSMail eat about 170 KB of memory, not
including the compiled in-memory table of your AREAS.BBS.
■ Depending on the amount of areas you carry and the number of
destination addressesper area, the compiled table of AREAS.BBS may
take 53 to 1516 bytes per individual area.
■ The maximum line length of each line in AREAS.BBS is 1024 characters.
■ The maximum size of processed messages is 32000 bytes.
■ The maximum size of incoming and outgoing mailbundles is 2 Gigabyte.
■ The maximum number of individual areas in AREAS.BBS is 512.
■ The maximum number of destination addresses per area in AREAS.BBS is
50.
■ The maximum number of messages in a RBBS-PC messages file is 999.
■ The maximum number of messages in a FIDO .MSG style subdirectory is
2048.
■ The maximum number of net/node pairs in the SEEN-BY and PATH lines is
256.
■ The maximum length of any AREA: name is 64 characters.
■ The maximum length of any drive:\subdir\filename.ext is 64
characters.
What is RBBSMail 3
RBBSMail v18.1
2.4 Related Documents
I advise you (well, it is sort of mandatory) to read or at least browse
through the following documents:
■ The manual of the frontend mailer you intend to use.
■ SD-APDX by Kim Wells (how to run SEADOG with RBBS-PC).
■ BT-APDX by Tony Young (how to run BinkleyTerm with RBBS-PC).
■ The IFNA FTS documents.
■ IFNA publications about the FIDONET.
■ The FIDO newsletters.
And you already read the RBBS-PC documentation, didn't you??? Or did you
just fire up RBBS-PC with your fingers crossed? If you are one of those
who never reads documentation, you'll probably will not read this. But,
in case your eye accidentially catches this: Please read the documentation
before you ask any questions!!! I have had too many questions asked by
people that obviously did not read a scrap of documentation before they
started what they were doing. I have a standard answer for these people:
R.T.F.M.!! This answer will usally solve some 95% of the questions. The
other 5% are 'real' problems that need some sort of action. If, after
reading and rereading the documentation there are still questions
unanswered, feel free to contact the author and elaborate on your
problem.
2.5 Acknowledgements
It is utterly impossible to give credits were credits are due, but here
are the names of some persons that have been of great help and deserve
kudos: Thom Mack, Ken Goosens and Jon Martin, authors of RBBS-PC. Doug
Azzarito and Kim Wells for their many suggestions. Jeff Rush, author of
TOSSMAIL and SCANMAIL, and the inventor of Echomail. The Binkley Trio.
Johan Zwiekhorst for GUS and the ARCA simulator. Bob Hartman for making
the source of ConfMail available. Ron Bemis for his many useful
suggestions and sample C code in the international NET_DEV conference on
FIDONET. Mark Kimes for some refreshing ideas and the wording of the
license agreement.
And last (but NOT least!) the people that had the courage to beta-test my
code. A special word of thanks to Patty Pickett, sysop of "My Secret
Garden RBBS". Patty asked lots of questions setting my brain in gear,
provided feedback on errors in the program and documentation and she
volunteered to distribute updates to the beta-testers. Kisses, Patty! You
earned yourself an original Dutch Cheese :-)
What is RBBSMail 4
RBBSMail v18.1
│ 3. Legal Stuff
│ 3.1 Copyrights & License
│ RBBSMail is (C) Copyright 1988...1991 by Jan R. Terpstra.
│ Non-Commercial distribution and/or use is permitted under the following
│ terms::
│ 1 - You may copy and distribute verbatim copies of RBBSMail source,
│ documentation, and executable code as you receive it, in any medium,
│ provided that:
│ ■ you conspicuously and appropriately publish on each copy a valid
│ copyright notice "(C) Copyright 1987, 1992 by Jan R. Terpstra";
│ ■ you keep intact the notices on all files that refer to this License
│ Agreement and to the absence of any warranty;
│ ■ you provide UNMODIFIED copies of the documentation as provided with
│ the program;
│ ■ you give any other recipients of the RBBSMail program a copy of this
│ License Agreement along with the program.
│ 2 - You may not charge a distribution fee for the physical act of
│ transferring a copy. Under no circumstances is RBBSMail to be distributed
│ in such a way as to be construed as "value added" in a sales transaction,
│ such as, but not limited to, software bundled with a modem or CD-ROM
│ software collections.
│ 3 - You may modify your copy or copies of RBBSMail or any portion of it,
│ and copy and distribute such modifications under the terms of Paragraph 1
│ above, provided that you:
│ ■ send a complete copy of the modified source and executables to Jan R.
│ Terpstra at the address on the title page of this document, for the
│ purpose of evaluation for inclusion in future releases of RBBSMail.
│ Should your source code be included in RBBSMail, Jan R. Terpstra
│ retains all rights for redistribution of the code as part of RBBSMail
│ and all derivative works, with appropriate credit given to the author
│ of the modification,
│ ■ cause the modified files to carry prominent notices stating that you
│ changed the files and the date of any change,
│ ■ cause the executable code of such modified version to clearly identify
│ itself as such in the course of its normal operation,
│ ■ If the modified version is not a "port", but operates in the same
│ hardware and/or software environment as the original distribution,
│ make the original version equally available, clearly identifying same
│ as the original, unmodified version;
│ ■ cause the whole of any work that you distribute or publish, that in
│ whole or in part contains or is a derivative of RBBSMail or any part
│ thereof, to be licensed at no charge to all third parties on terms
│ identical to those contained in this License Agreement (except that
│ you may choose to grant more extensive warranty protection to some or
│ all third parties, at your option),
Legal Stuff 5
RBBSMail v18.1
│ ■ You may not charge a distribution fee for the physical act of
│ transferring a copy. You may not offer warranty protection in
│ exchange for a fee.
│ 4 - Mere aggregation of another unrelated program with this program and
│ documentation (or derivative works) on a volume of a storage or
│ distribution medium does not bring the other program under the scope of
│ these terms.
│ 5 - You may copy and distribute RBBSMail and its associated documentation
│ (or a portion or derivative of it, under Paragraph 2) in object code or
│ executable form under the terms of Paragraphs 1, 2 and 3 above provided
│ that you also do one of the following:
│ accompany it with the complete corresponding machine-readable source code,
│ which must be distributed under the terms of Paragraphs 1, 2 and 3 above,
│ OR
│ accompany it with a written offer, valid for at least three years, to give
│ any third party free a complete machine-readable copy of the corresponding
│ source code, to be distributed under the terms of Paragraphs 1, 2 and 3
│ above,
│ OR
│ accompany it with the information you received as to where the
│ corresponding source code may be obtained. (This alternative is allowed
│ only for noncommercial distribution and only if you received the program
│ in object code or executable form alone.)
│ For an executable file, complete source code means all the source code for
│ all modules it contains. As exception, it need not include source code
│ for modules which are standard libraries that accompany the compiler used
│ to generate the object code or libraries that are part of the operating
│ system on which the executable file runs.
│ 6 - You may not copy, sublicense, distribute or transfer RBBSMail and its
│ associated documentation except as expressly provided under this License
│ Agreement. Any attempt otherwise to copy, sublicense, distribute or
│ transfer RBBSMail is void and your rights to use the program under this
│ License agreement shall be automatically terminated. However, parties who
│ have received computer software programs from you with this License
│ Agreement will not have their licenses terminated so long as such parties
│ remain in full compliance, and notify Jan R. Terpstra of their intention
│ to comply with this Agreement.
│ 7 - If you wish to incorporate parts of RBBSMail into other free programs
│ whose distribution conditions are different, please contact Jan R.
│ Terpstra at the address listed below. There's not yet a simple rule that
│ can be stated here, but it will usually be permitted this. Such decision
│ is guided by the two goals of preserving the free status of all
│ derivatives of this free software (as it pertains to Non-Commercial use as
│ provided by this Agreement) and of promoting the sharing and reuse of
Legal Stuff 6
RBBSMail v18.1
│ software.
│ 8 - For the purposes of this document, "COMMERCIAL USE" is defined as
│ operation of the software with the intent of generating financial revenue,
│ where the revenue excesses the true costs of running the organisation
│ (i.e. profit). The term "COMMERCIAL USE" includes use by religious
│ organisations, government agencies and organisation raising funds for
│ third parties.
│ NON-PROFIT non-religious organization or individuals may operate this
│ software under the terms of this Non-Commercial Agreement.
│ 9 - You may terminate this license at any time by simply destroying all
│ copies of the RBBSMail executables, sourcecode and documentation you have
│ in your posession.
│ 3.2 NO WARRANTY
│ BECAUSE RBBSMail IS LICENSED FREE OF CHARGE, I PROVIDE ABSOLUTELY NO
│ WARRANTY. EXCEPT WHEN OTHERWISE STATED IN WRITING, JAN R. TERPSTRA
│ AND/OR OTHER PARTIES PROVIDE RBBSMail "AS IS" WITHOUT WARRANTY OF ANY
│ KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
│ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
│ PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF RBBSMail,
│ AND THE ACCURACY OF ITS ASSOCIATED DOCUMENTATION, IS WITH YOU. SHOULD
│ RBBSMail OR ITS ASSOCIATED DOCUMENTATION PROVE DEFECTIVE, YOU ASSUME THE
│ COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
│ IN NO EVENT WILL JAN R. TERPSTRA BE RESPONSIBLE IN ANY WAY FOR THE
│ BEHAVIOR OF MODIFIED VERSIONS OF RBBSMail. IN NO EVENT WILL Jan R.
│ Terpstra AND/OR ANY OTHER PARTY WHO MAY MODIFY AND REDISTRIBUTE RBBSMail
│ AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY LOST
│ PROFITS, LOST MONIES, OR OTHER SPECIAL, INCIDENTAL OR CONSEQUENTIAL
│ DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
│ LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES
│ SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
│ OTHER PROGRAMS) RBBSMail, EVEN IF YOU HAVE BEEN ADVISED OF THE POSSIBILITY
│ OF SUCH DAMAGES, OR FOR ANY CLAIM BY ANY OTHER PARTY.
│ You can contact the author at address listed on the titelpage of this
│ document. Feel free to contact me at any time to share your comments
│ about my software and/or licensing policies. I don't always listen,
│ though.
│ For your info: RBBSMail was developed and tested on an IBM PS/2 mod70 with
│ 6MB memory and a 60MB fixed disk. This version has been tested with
│ RBBS-PC 17.3C, ConfMail v3.3, BinkleyTerm v2.50, oMMM v1.70, AMAX v2.20
│ and Maximus CBCS v2.00.
│ RBBSMail is entirely written in Microsoft QuickC/QuickASM v2.51. All
│ development and testing was done under IBM PC-DOS 3.30 and DESQView 2.26.
│ RBBSMail was tested to run in the DOS boxes of MS Windos 3.0 and the beta
│ 6.177 release of IBM OS/2 2.0.
Legal Stuff 7
RBBSMail v18.1
│ 3.3 NO MONEY
│ Non-Commercial users may us this software free of charge. If you
│ absolutely insist on spending money for RBBSMail, DO NOT put a check in
│ the mail to me. In stead, take your wife or girlfriend (not both!) out to
│ dinner, to make up for the many, many hours you left her alone while you
│ were playing around with your BBS.......
│ Therefore, it is understood that RBBSMail is distributed as DINNERWARE.
│ There's one absolute requirement for using this code: Send the author of
│ RBBSMail a nice postcard of a local scenery or from your next vacation.
│ No windmills please :-)
│ 3.4 The RBBS commitment
│ A quote from the RBBS docs: "Most Bulletin Board Software is dedicated to
│ making money for its authors. No matter how much the authors love the
│ work, it endures only so long as the hope of income continues.
│ RBBS is given away for free, and depends not on the flow of money, but on
│ the continuing dedication and generosity of people who volunteer to help
│ support and enhance it as a public service, and share their labor of love
│ with others for the benefit of all."
│ This statement fully applies to RBBSMail as well.
Legal Stuff 8
RBBSMail v18.1
4. Installation
4.1 Configuring RBBSMail
Installation of RBBSMail is pretty straightforward. The installation
procedure assumes that you have installed RBBS-PC and your frontend
mailer, with all the conferences, the RBBS-PC control files and suitable
batch files. You should already have obtained all the stuff you need to
run as a FIDONET node, things like NET/NODE number, the NODELIST and some
programs to maintain all the files. Please read the documentation of your
frontend mailer about this. Talk to the Sysop of your host-node about
setting up your mail schedules and mailrouting.
Now, copy RBBSMail.EXE to the directory where you keep your RBBS-PC
MESSAGE files. Find out the EXACT filenames of all the conferences you
are going to hook up in the Echomail and find out by what AREA:names they
are known in the network you are participating in. You also need the
NET/NODE number(s) of the system(s) you are going exchange echomail with.
You can send any AREA: to a large number of different systems. This is
usually not the case, you will probably exchange mail with a small number
of neigbouring nodes or only with your Echomail HOST, HUB or backbone.
Most local FIDONET nets have a single hostnode with some 5 to 20 nodes
connected. Ask the sysop of your local or regional HOST/HUB for the EXACT
AREA: names used in your net.
RBBSMail can run your system as Echomail host so you can set up your own
local or regional net.
If you have all info needed, you must build two control files for
RBBSMail. One is RBBSMAIL.CFG, containing the information RBBSMail needs
to make your system talks to the rest of the net. The other is AREAS.BBS,
the control file that lists all echomail areas you exchange with other
nodes. We'll talk about AREAS.BBS later on.
The format of RBBSMAIL.CFG file has a layout similar to the configuration
files used by BinkleyTerm, MsgEd and other FIDONET utilities. In fact you
can run RBBSMail, MsgEd and BinkleyTerm using only a single configuration
file by writing "application rbbsmail" in front of the RBBSMail specific
configuration phrases in BINKLEY.CFG. Refer to section "Reading
BINKLEY.CFG" in this manual or the BinkleyTerm documentation for more
info.
4.2 Valid phrases for RBBSMAIL.CFG
4.2.1 Address
Up to 10 FULL ZONE:NET/NODE.POINT addresses. For normal operation, the
full FIDONET address(es) under which you are listed in the nodelist. For
point operation, it is the full 4-dimensional address of your point. For
point operation, RBBSMail will translate the address internally to the
proper fakenet address. (See also the PRIVATENET phrase).
Installation 9
RBBSMail v18.1
You may specify up to 9 additional addresses (i.e. AKA, Also Known As
addresses). The FIRST address listed in the configration file will be
used as your primary address. The additional addresses are ignored for
point operation.
For compatability with the BinkleyTerm configuration file, you may either
write your primary address as the full ZONE:NET/NODE.POINT@domain address
or specify (override) it with the the DOMAIN configuration phrase in
RBBSMAIL.CFG.
Only the domain name of your primary address is used, domains for AKA
addresses are ignored.
4.2.2 ARCto, ARJto, PAKto, LHAto, ZIPto, ZOOto.
RBBSMail can use different compression methods for outgoing ARCmail to
different addresses. You can tell RBBSMail what compression method to use
for a certain address by using the PAKto, ARJto, LHAto, ZIPto or ZOOto
configuration phrases in the format:
XXXto <address> <address> <address> <address>
This is perhaps best illustrated with an excerpt from a RBBSMAIL.CFG file:
ARJto 8:900/1 ; this one gets ARJ mail
LHAto 1:1/1 ; he prefers LHA (LHARC)
PAKto 2:512/8 ; this node gets PAK format ARCmail
ZIPto 2:555/666 2:789/789 ; but these guys can only handle ZIP mail
ZOOto 2:1010/2 2:1010/3 ; and finally a 2 ZOO lovers
If an address is not listed for one of the preferred compression methods,
RBBSMail will default to old style ARCmail compatible mailbundles by
calling the program ARCA.
For this option to work properly, the executable files ARJ.EXE PAK.EXE,
LHA.EXE, PKZIP.EXE and ZOO.EXE must be in the current subdirectory or in a
subdirectory listed in your DOS PATH.
These ARCmail options have only effect when using the command line
switches -OF or -FA.
When using command line switches -OB or -OP, an external mailpacker (see
PACK configuration phrase) will be invoked and RBBSMail will not use the
internal ARCmail routines.
Warning to ARCmail users:
If you run Binkley as frontend mailer and oMMM as mailpacker, BE SURE that
both RBBSMail's ARCmail options and oMMM's Stuffer<tm> options invoke
compression methods for the individual destination nodes! Otherwise the
destination node may receive an ARCmail bundle containing mailbundles
compressed by different compression programs.
If you use RBBSMail's internal ARCmail routines (either the -FA or -OF
command line switch) and ALSO run oMMM to compress and route ARCmailed
mailbundles, you may want to employ Johan Zwiekhorst's ARCA simulator. If
you do not configure any of RBBSMail's ARCmail options or oMMM's
Installation 10
RBBSMail v18.1
stuffer<tm> options, both programs will happily use Johan's ARCA simulator
as a drop-in replacement for ARCA.
Johan's ARCA simulator has an external configuration file that allows you
to set different compression methods for different destination addresses.
Using the ARCA simulator will ensure that the same compression program is
used for each individual destination node, both by RBBSMail and OMMM.
Plus you only need to change ARCA's config file if your distribution
changes and you don't have to bother with either RBBSMail's ARCmail
options or oMMM's stuffer<tm> option.
4.2.3 Domain
This is the common name of the network you are a member of under your
PRIMARY net/node number. DOMAIN is used to build the MSGID: tags for
messages originating from your system and can be any valid domain name:
RBBSNet, FIDONET, Eggnet, AlterNet or whatever network you are in.
4.2.4 DupSize
Tells RBBSMail how many message identifications of impoted messages (per
conference) it should store for purpose of checking for duplicate
messages. The value can be 0... 3200, default is 512. A value of 0
disables the duplicate checkig entirely.
A higher value for DupSize makes RBBSMail perform slightly slower when
importing messages.
For systems with a low load of echomail, DupSize 200 will do. On systems
with an average load of echomail, the default is probably a good enough.
If you often find duplicate messages not caught by RBBSMail, increase the
value of DupSize.
│ 4.2.5 ExportComments
│ Normally, Comments and Private messages to Sysop aren't exported. In case
│ you have a co-sysop running as one of your points, he may wish to see
│ comments and private messages to sysop as well. You can tell RBBSMail to
│ export comments and private messages to sysop with this configuration
│ phrase.
│ :mote
│ Be warned that potentially ANYONE can read whatever confidential info in
│ messages and comments to sysop once the message has left your system!!
4.2.6 Gate
ZONE:NET/NODE address of a ZONEgate or ECHOgate (HUB), followed by the
NET/NODE number that should appear in the SEEN-BY lines in messages
addressed to that gateway node.
Normally, a SEEN-BY line to an ECHOgate or ZONEgate only contains the
gate's NET/NODE and the NET/NODE (and applicable AKA addresses) of your
Installation 11
RBBSMail v18.1
own system. You may define up to 10 gates. Ignored for point operation.
If you are serving as Echomail hostsystem and also send echoes to the host
of another net, you and the other hosts are only concerned about the
SEEN-BY info for your respective nets only and there is no need to carry
all SEEN-BY info over to the other net. The two host systems only have to
tell each other the fact that they have seen the message. All other info
about what happened to the message in the one net is of no interest to the
other net. Having a short SEEN-BY line keeps down the mailcost for ZONE
and ECHO gates.
4.2.7 Hold
This is the subdirectory where RBBSMail writes outgoing mailbundles or
ARCmailed bundles.
If you send echomail to other zones than the zone your in, you also need
to have the proper subdirectories for outbound mail to those zones. If
"HOLD C:\BINKLEY\HOLD" is specified as outbound subdirectory and you send
mail to Zone 8, the subdirectory C:\BINKLEY\HOLD.008 must also be
present.
4.2.8 ImportDate
This phrase tells RBBSMail to stamp local messages with the CURRENT date,
not with the date the message was originally entered. All impoted
messages will carry the date/time stamp of the moment the message was
imported to your system. If you kill messages by age, then the message
age will be calculated from the moment the message arrived on your
system. In echomail conferences with a high amount of traffic you may
wish to kill messages after a short time. Thus there's a chances that
your message maintenance utility will kill an imported message the same
day.
Note: This option works for RBBS-PC style messages files only.
4.2.9 Indomain
See section "CrossZone Echomail" for information about setting up a
Network Gateway system. This phrase is ignored for POINT operation.
4.2.10 KillNull
This phrase tells RBBSMail to discard all messages without human readable
contents. Control information (i.e. any text "hidden" by a Ctrl-A
kludge") is not treated as human readable text. This option is especially
usefull to automatically kill FileAttach, FileRequest or empty messages.
This option can also be switched on with the -KN commandline switch.
Installation 12
RBBSMail v18.1
4.2.11 LogLevel
This phrase tell RBBSMail which error messages, progress messagess and
reports it should write to the logfile. Loglevel can be any value between
0 and 4, which has the following effect
0 Do not write to the log at all.
1 Only log critical errors.
2 Log critical and non-critical errors.
3 Log critical errors, non-critical errors and progress messages.
4 Log critical errors, non-critical errors, progress messages and
statistics.
See also configuration phrase StatusLog.
4.2.12 MaxOut
This tells RBBSMail after how many exported messages it should invoke the
mailpacking routine. When the -OB or -OP command line switch is given,
RBBSMail will invoke the external mailpacker. See also the PACK phrase
below.
If the -FA or -OF comandline switch is given, RBBSMail will run the
internal ARCmail routines each time after MaxOut messages are exported.
By packing outgoing mail each time a certain number of messages is
exported, your outgoing mailbundles will be relatively small in size.
Some other echomail processors, like ConfMail, work more effectively with
small mailbundles. The number behind MaxOut can be between 1 and 32676.
A value between 25 and 250 is recommended.
4.2.13 NetFile
Subdirectory where RBBSMail can find incoming FTS-0001 compatible
mailbundles.
4.2.14 NoRts
Normally, RBBSMail returns all incorrect echomail messages to the
orignator and tosses a copy to the BAD_MSGS area for later inspection. If
the phrase NoRts is present, RBBSMail will not return incorrect messages
to the sender.
See also the -S command line option and the SecureMail configuration
phrase.
4.2.15 NoStinkingKludgeLines
This option causes RBBSMail to strip all redundant "kluge lines" from all
incoming echomail messages. Only AREA, EID, MSGID, REPLY, SEEN-BY and
PATH kludges will be left intact. All others, including idiocy like PID,
OSE and Via will be removed from the echomail messages.
Installation 13
RBBSMail v18.1
4.2.16 OpusDate
This phrase tells RBBSMail to write all FIDO style (*.MSG) messages as
Opus/Maximus compatible files. RBBSMail adds extra date/time info to the
message header. This allows you to do maintenance on those message bases
using Opus or Maximus utilities like Renum and ReplyLink.
4.2.17 Pack
The name the external packer program to be invoked by RBBSMail to packup
your outgoing mail. This normally calls oMMM or a similar mail packing
program to bundle and route outgoing mail. See also the MaxOut phrase
above.
The program listed after PACK can be either a BATchfile that invokes your
mail packer or the name and parameters of your mail packer. A PACK batch
file (for example named PACKMAIL.BAT) can look something like this if you
use BinkleyTerm, ReMapper and oMMM:
ECHO OFF
CD\BINKLEY
REMAPPER 9999 -fpi
oMMM -iBINKLEY.PRM -m\BT\MAIL -h\BT\HOLD -c\BT\OMMM.CTL -sA -z2
CD\RBBS
In this case, the RBBSMail entry should read
PACK C:\PACKMAIL.BAT
Or the PACK parameter could list oMMM directly, with all parameters:
PACK oMMM -i\BINKLEY.PRM -m\BT\MAIL -h\BT\HOLD -c\BT\OMMM.CTL -sA -z2
In this case, RBBSMail calls oMMM directly and you do not need a separate
BATchfile to run oMMM.
Today, it is very common to compress mailbundles before they are sent to
another system. This will in some cases save over 50% of connect time to
transfer mailbundles. For INcoming mailbundles, RBBSMail recognizes most
popular compression format internally and will invoke the proper
decompression program. Mailbundles compressed by ARC/PAK/PKARC, ARJ, LHA
(formerly known as LHARC), PKZIP and ZOO. If the compression method of a
mailbundle cannot be determnined, RBBSMail will try to invoke GUS, a
General Unpack Shell written by Johan Zwiekhorst.
for this to work properly, the executable files PAK.EXE, LHA.EXE,
PKUNZIP.EXE, ZOO.EXE and GUS.EXE must be in the current subdirectory or in
a subdirectory listed in your DOS PATH environment variable.
Note: If you decide to use this RBBSMail feature, BE SURE you have enough
memory to run RBBSMail, oMMM and ARCA on top of each other! 320KB free
memory when starting RBBSMail with this feature is the bare minimum.
Installation 14
RBBSMail v18.1
4.2.18 PrivateNet
Is the NETnumber of your private network for points. RBBSMail will strip
all point addresses from the SEEN-BY: lines in outgoing mail, but retains
the addresses locally. PRIVATENET is mandatory for both Boss AND point
operation.
4.2.19 Size
Maximum size (in BYTES) of incoming messages. All messages larger than
this will be ignored. RBBSMail's internal limit is 32000 bytes for all
messages, but you may want to set this to a lower value.
Note: Most sysops pay the bill for Echomail out of their own pocket, so
messages in the Echomail should be kept small. Sending Echomail messages
that are over 10KB in size may be considered anti-social.....
4.2.20 Security
The security all imported messages are set to. A user has to have at
least this access level to read any imported Echomail. Ignored for
messages in FIDO style message subdirectories.
4.2.21 SecureMail
This phrase tells RBBSMail to always handle echomail in secure mode.
Effectively this tells RBBSMail to always assume that the -S comand switch
was given.
See the -S command line option for details.
4.2.22 StatusLog
The name of the logfile to use. If no StatusLog is specified, filename
RBBSMAIL.LOG is used.
See also the LogLevel configuration prhase.
4.2.23 StripSeen
If this phrase is configured, RBBSMail will strip the SEEN-BY and PATH
lines from all messages imported to RBBS-PCstyle message bases. Since
messages in RBBS-PC conferences are never exported once they're imported,
the SEEN-BY and PATH lines have no purpose once the message has been
written to a RBBS-PC conference file. The echomail control lines can be
stripped to save some diskspace.
If you ever need inspect the flow of the echomail distribution, for
instance if your systems receives lots of duplicate messages or just
because you're curious, you do need the echomail control lines. If so, do
not set StripSeen in RBBSMAIL.CFG.
Installation 15
RBBSMail v18.1
4.2.24 SysAlias
The alias name sysop uses to logon remotely to RBBS-PC. Beginning with
RBBS-PC v16.1A, the sysop's alias name is listed in the USERS file.
RBBSMail needs to know this alias to find the sysop entry in the USERS
file to be able to flip the 'messages waiting' indicator for the sysop.
4.2.25 Sysop
The name you are normally known under as sysop of this system. Whatever
you specify here will be overridden if you specify a SYSOP name after the
Origin line in AREAS.BBS.
4.2.26 Reading BINKLEY.CFG
Like noted before, RBBSMail is capable of using the configuration file of
other programs like BinkleyTerm's configuration file. The configuration
phrases Address, Netfile, Hold, Sysop and Privatenet are read directly
from Binkleyterm's configuration file.
RBBSMail configuration phrases can be added to BINKLEY.CFG by putting
APPLICATION RBBSMAIL in front of the configuration phrase.
For example, to enter the SECURITY phrase in BINKLEY.CFG, add the line:
Application RBBSMail Security 4
See the BinkleyTerm documentation for more info.
Note: As RBBSMAIL cannot read nested configuration files, you cannot use
the INCLUDE statement in your BINKLEY.CFG file.
Installation 16
RBBSMail v18.1
4.2.27 Example of a RBBSMAIL.CFG file
; Lines starting with a ';' are comment lines. BLANK lines are ignored.
;
Address 2:512/10.0
Address 2:512/101.0
Address 8:998/1.0
Address 8:998/0.0
Domain FIDONET
NetFile C:\BT\NETFILES\
Hold C:\BT\HOLD\
PrivateNet 9999
SysAlias Buck Rogers
Sysop John Software
Size 9000
Security 4
Gate 1:1/0 1/0 512/10 101
Gate 2:2/0 2/0 512/10 101
Gate 3:3/0 3/0 512/10 101
Gate 8:8/0 8/0 512/10 926/0 1
Pack C:\BINKLEY\PACKMAIL.BAT
ZIPto 2:2512/10 2:512/101
PAKto 8:926/1
NoStinkingKludgeLines
SecureMail
DupSize 1024
ImportDate
(another example is included in this package, see file EXAMPLE.CFG).
Put the config file RBBSMAIL.CFG in your RBBS-PC directory, edit the
entries to reflect your specific system setup and remove all comments for
speed.
Installation 17
RBBSMail v18.1
The second file you need is named AREAS.BBS (for historic reasons). This
file lists all the conferences you want to hook up to Echomail, the AREA:
tag for that conference and the NET/NODE number you want to send the
Echomail to.
4.2.28 Example of an AREAS.BBS file
; Lines starting with ';' or '-' are comment lines, so are BLANK lines
; First non-commented line has the Origin line ! optional SYSOP name
The Tennis Court, Herejezusveen, The Netherlands ! John Software
; all subsequent lines have either
; RbbsFileName AreaName SendToList
; or
; MsgSubdir AreaName SendToList
;
; You MUST at least have the areas NETMAIL and BAD_MSGS in your AREAS.BBS file
; Per conference, you can have up to 50 destination zone:net/node numbers.
C:\BINK\NETMAIL\ NETMAIL
C:\BINK\BAD_MSGS\ BAD_MSGS
C:\RBBS\TENNISM.DEF +TENNIS 2:512/1 2 8:926/1 8:999/1 2:1234/1 2
C:\RBBS\IBMPCM.DEF -IBM-PC 2:512/1 2 3 12 8:926/1
C:\RBBS\RBBSM.DEF RBBS-PC 2:512/1 6 8:926/1
C:\BINK\SYSOPS\ SYSOP 2:512/1
C:\BINK\PASSTHRU\ WINDOWS 2:512/1
C:\BINK\PASSTHRU\ XMODEM 2:512/1
(see also EXAMPLE.BBS in this package).
This AREAS.BBS example will have the following result:
■ The string "The Tenniscourt, Herejezusveen, The Netherlands" will be
used as the * Origin: line in all outgoing Echomail originating from
your system. This way, anybody on any other system will know where
the message was originally entered.
■ If an outgoing message has SYSOP in the address field, it will be
replaced by the name John Software. This way, other sysops will not
find that message addressed to themselves, avoiding confusion.
If you specify the OPTIONAL sysop name this way, it will overrride the
SYSOP entry of RBBSMAIL.CFG.
■ If an incoming message has John Software in the address field, it will
be replaced by SYSOP. This way, the message scan function of RBBS-PC
will identify those messages as being addressed to SYSOP.
■ All messages in the file TENNISM.DEF will be sent to nodes 512/1 and
512/2 in ZONE 2, to nodes 926/1 and 999/1 in zone 8, and they will be
sent to the nodes in the private (point) network 1234/1 and 1234/2.
When sent out, an AREA: tag TENNIS will be put in the first line of
the message. This way the receiving system on the other end knows
what to do with the message. When importing incoming mail, messages
Installation 18
RBBSMail v18.1
with an AREA: tag TENNIS will be put in the TENNISM.DEF file.
■ The area SYSOPS does not refer to an RBBS-PC MESSAGES file, but to a
subirectory that holds FIDO style messages. If a message with
AREA:SYSOPS is received, it will be moved to the subdirectory
C:\BINK\SYSOPS\, where it can be read by an appropriate message editor
like MsgEd or Dutchie's Editor. RBBSMail sees the difference between
RBBS-PC MESSAGES files and FIDO subdirectories by itself. If RBBSMAil
finds that a message base is a real file, a RBBS-PC MESSAGES file is
assumed. If the message base is a subdirectory, RBBSMail will treat
the conference as a FIDO style message subdirectory.
■ You can probably figure out by yourself what happens to the other two
conference files RBBS-PC and IBM-PC? Well, sort of......
There are two special cases in this example of AREAS.BBS, the WINDOWS and
the XMODEM area. They are listed using the same message subdirectory
C:\BINK\PASSTHRU\. This may look like mixing up two entirely different
echomail conferences, but it isn't. If RBBSMail finds that an echomail
uses the special subdirectory PASSTHRU, it will normally process all
messages for that area. All checking for proper control echomail lines
and duplicates will be performed, but a local copy of the message will
never be written. The echomail is just "passing through" and does not
actually exist on the local system. An empty subdirectory \PASSTHRU is
needed for this feature.
This comes in quite handy if a system is forwarding echomail for others
because it has a cheap phone line or has cheap calls to two or more
neighbouring telephone districts.
You may add a '+' or a '-' in front of the area name. The line defining
the TENNIS conference tells RBBSMail to allow import and export of private
messages, i.e. the message's attributes will remain unchanged. The line
defining the IBMPC-PC conference tell RBBSMail to discard all messages
that have a message attribute of Private.
By default, RBBSMail will force all incoming and outgoing messages in all
conferences to be PUBLIC messages, except for private messages and
comments to sysop.
This example has all your Echomail information in one file. You may have
different AREAS.BBS-type files with different names and different Origin
lines. For instance, you could have a TENNIS.BBS file like:
The Tennis Court, Herejezusveen, The Netherlands ! John Software
C:\RBBS\TENNISM.DEF +TENNIS 2:512/1 2 8:926/1 8:999/1 2:1234/1 2
Or an IBMPC.BBS file with:
The Tennis Court, IBM PC Tech support, The Netherlands ! John Software
C:\RBBS\IBMPCM.DEF -IBM-PC 2:512/1 2 3 12 8:926/1
When you invoke RBBSMail SCAN explicitly giving TENNIS.BBS or IBMPC.BBS
(see next chapter) it will take the sysop name, Origin line and
distribution info from that file. This way, you can put different things
in you Origin line and process Echomail conferences separately and at
Installation 19
RBBSMail v18.1
different times.
Installation 20
RBBSMail v18.1
5. Running RBBSMail
Beginning with version 18.0, a number of safeguards have been build in
RBBSMail to ensure RBBS-PC MESSAGES file integrity while TOSSing mail into
RBBS-PC style conferences. You do not need to bring down all your nodes
when running RBBSMail. You can have users reading and writing messages
on-line while at the same have RBBSMail handle incoming and outgoing
echomail.
There is one requirement to maintain message base integrity. Using
RBBS-PC's CONFIG program, you must set the option "Message file grows as
messages are added" to YES and the "Maximum number of messages per
conference" must be set to 999 RBBSMail will not work properly if these
values are set otherwise.
Unlike previous versions of RBBSMail, version 18.x imports and exports all
echomail in ONE single sweep. There's no need to specifically run
RBBSMail TOSS or RBBSMail SCAN. Also, the MAINT mode of RBBSMail has been
removed, there is now a separate program RBBSMNT to do maintenance on
RBBS-PC's messages files.
5.1 Commandline options
5.1.1 -A <areasbbsfile>
Use an alternate areas listing. RBBSMail defaults to AREAS.BBS (i.e. -A
AREAS.BBS).
5.1.2 -AKA #
Use # of AKA addresses (# is a number from 1 to 10). This tells RBBSMail
to put '#' of your AKA addresses in the SEEN-BY: lines. Addresses are
counted from top to bottom in your RBBSMAIL.CFG file. The first address
is used as your primary address, subsequent ADDRESS phrases are treated as
AKA addresses. RBBSMail uses no AKA addresses by default.
5.1.3 -BM
This switch tells RBBSMail to import messages from the BAD_MSGS area. If
you connected a new echomail area but did not create that area on your
system or list it in your AREAS.BBS file, then RBBSMail will toss messages
for that area to your BAD_MSGS subdirectory.
Instead of manually moving these messages to your netmail directory and
importing them after you've created the appropriate area, just create the
area, list it in your AREAS.BBS and run RBBSMail -BM to import the failed
messages.
Running RBBSMail 21
RBBSMail v18.1
5.1.4 -C <configfile>
The -C: switch allows you to use <configfile> as alternate configuration
file. Default is RBBSMAIL.CFG (i.e. -C RBBSMAIL.CFG)
5.1.5 -FA
Send outgoing echomail as FileAttached ARCmail. This switch forces
RBBSMail to build compressed mailbundles and a FilAttach message. Use
this option if your frontend mailer does NOT use oMMM as message
packer/router.
The FileAttach messages can then be processed by the frontend's own
message router. This is Recommended if RBBSMail is used in combination
with Dutchie or SEAdog. This option disregards the external mailpacker
and uses RBBSMail's internal ARcmail handler.
See also the MaxOut, PACK and ARCmail configuration phrases.
Note: NEVER change the status of the FileAttach messages RBBSMail writes
in your netmail subdirectory. These messages are used by RBBSMail to keep
track of sent and unsent ARCmail bundles and should not be changed or
deleted.
Note: The -FA, -OB, -OF and -OP switches are mutually exclusive.
5.1.6 -H
Use the FTS-0001 approved Ctrl-A kludge to hide the SEEN-BY lines. For
compatability only, NOT recommended for real life use.
5.1.7 -I
Process INBOUND mail only. This command line switch tells RBBSMail that
is should only process the incoming mailbundles for import and not export
the messages that were entered locally. This option especially usefull on
echomail backbones and apssthru nodes receiving echomail all through the
day, but have little or no messages entered locally.
5.1.8 -KN
Kill all messages without human readable contents.
See also the KillNull configuration phrase.
5.1.9 -OB
Build Outbound Bundles. This forces RBBSmail to write outgoing echomail
in the HOLD subdirectory as oMMM/Binkley/Opus compatbile .OUT type
mailbundles. A suitable mailpacker like oMMM can be used at a later time
to pack and route the outgoing mail.
See also the MaxOut and PACK configuration phrases.
Running RBBSMail 22
RBBSMail v18.1
Note: The -FA, -OB, -OF and -OP switches are mutually exclusive.
5.1.10 -OF
Build outbound FLO files like oMMM does. After writing the outgoing
echomail as .OUT mailbundles, RBBSMail compresses the bundles and writes
oMMM/Binkley compatible FLO files to the outbound subdirectory. The FLO
files are used by Binkley to determine where to send the mailbundles. The
status of FLO files can be handled manually or automatically by oMMM or
AMAX.
See also the MaxOut, PACK and ARCmail configuration phrases.
Note: The -FA, -OB, -OF and -OP switches are mutually exclusive.
5.1.11 -OP
Build Outbound Packets. This command line switch causes RBBSMail to write
outgoing echomail as SEAdog compatible .PKT files in the Hold
subdirectory. The bundles may then be processed at a later time by a
suitable packer/router.
Note: The -FA, -OB, -OF and -OP switches are mutually exclusive.
5.1.12 -P
Protect bundles. Normally, after RBBSMail uncompresses and unpacks
incoming mailbundles, the bundles are deleted. In some cases, other
programs may wish to do something with the incoming mailbundles too. The
-P command line option causes RBBSmail uncompress and unpack the
mailbundles normally, but it leaves all processed bundles intact.
The program processing the bundles left by RBBSMail should be run
IMMEDITATELY after RBBSMail is done. If not, there may be old bundles
left the next time RBBSMail run. RBBSMail will then unpack the same
bundles again and will find all messages in the old bundles to be
duplicate messages.
5.1.13 -S
Operate in secure mode. This forces RBBSMail to check all incoming
echomail to originate from an addess that is listed in AREAS.BBS. If an
echomail message is received from an address that is NOT listed in the
distribution list for that area, the message is tossed in the BAD_MSGS
subdirectory and a copy of the offending message, with a short
explanation, is returned to the originator. message
See also the SecureMail and NoRts configuration phrases.
Running RBBSMail 23
RBBSMail v18.1
5.1.14 -T
Use Tiny SEEN-BY lines. This will force RBBSMail to put only the
addresses from the distribution list (AREAS.BBS) in the SEEN-BY lines.
Use with extreme care, tiny SEEN-BY lines have been known to cause
duplicate messages in networks that suffer from circular distribution of
echomail.
5.1.15 -X
Exclude processing of the netmail subdirectory. This forces RBBSMail to
look for incoming echomail as mailbundles or ARCmail bundles only.
Greatly speeds up the import of incoming mail.
Running RBBSMail 24
RBBSMail v18.1
6. A word on echomail distribution
When RBBSMail is invoked, it will read the lines of RBBSMAIL.CFG and
AREAS.BBS. If there are distribution lists in the AREAS.BBS file,
RBBSMail first searches all echomail conferences (RBBS-PC MESSAGES files
and FIDO style message bases) for new messages and sends copies of these
messages to their destionations.
RBBSMail does a few checks before it exports a message. If the TO or FROM
field of a message contains "SYSOP", it is replaced by the sysops's real
name. This hopefully prevents confusion about "what sysop the message is
addressed to?" when the message arrives on other systems.
RBBS-PC allows users of the BBS to enter comments to SYSOP in
conferences. If the SUBJECT filed of a message contains the word
"COMMENT", the message is not exported.
Depending on the setting of '+' and '-' in AREAS.BBS, RBBSMail wil ignore
private messages, send them as-is or force them to be public messages.
If a message contains NOECHO (just one word, in UPPER case) as the first
line of the message text, RBBSMail will NOT send that message out on the
network. So, if there's anything to be said in a conference that only
concerns users on YOUR system, put NOECHO as first line of the message and
that message will not be send to other systems. Inform your users about
this feature!
During the process of exporting messages, new messages will be tagged with
an MSGID: (Message Identification) tag at the top of all outgoing
messages. The MSGID: tag is a unique message identifier in the format
MSGID: Z:N/N/P yyyyyyyy
where:
Z:N/N.P is your full Zone:Net/Node.Point address
yyyyyyyy = a DOS style date&time marker.
The date/time stamp plus the 16 bit CRC of the From, To and Subject fields
of the message are used to generate an identifier that can be used to
check for duplicate messages. Another identifier is stored in a file
named xxxx.DUP (where xxxx is the name of the current conference). This
is a wrap around file, holding the IDs of the last incoming and outgoing
echo messages for each area.
The number of message IDs (and thus the size of the dups file) can be set
with the configuration phrase DupSize in RBBSMAIL.CFG.
Next, RBBSMAil looks for incoming mail in the MAIL and NETFILE
directories. After checking for proper addressing and duplicate messages,
RBBSMail will send a copy of the incoming messages to the destination list
and then toss it to either the appropriate RBBS-PC conference or to the
proper FIDO style message subdirectory listed in AREAS.BBS.
If there is no RBBS-PC conference file or FIDO message subdirectory
related to the AREA:tag, the message is tossed to the BAD_MSGS area.
When importing mail, RBBSMail will look for a USERS file belonging to the
conference it writes any message to. This USERS file is scanned for the
A word on echomail distribution 25
RBBSMail v18.1
name the message is addressed to. If the name is found, the 'mail
waiting' bit for this user will be flipped ON. If you use the new mail
notification or the [V]iew conferences feature of RBBS-PC (i.e. you have
a CONFMAIL.DEF type file), users can quickly check for new mail in the
conferences, without having to access each conference separately.
Note: USERS file update only works for RBBS-PC MESSAGES files, not for
FIDO style message subdirectories.
Echomail messages addressed to net/node numbers other than your net/node
number(s) are tossed to the BAD_MSGS directory. NETmail messages (i.e.
messages without an AREA:tag) are ignored and left intact in the NETMAIL
directory.
A word on echomail distribution 26
RBBSMail v18.1
7. A word on RBBS-PC MESSAGES files
7.1 Filesizes
When you installed RBBS-PC, it required you to tell it what the size (in
128 byte records) of your MESSAGES files should be, how many lines per
message you allow and what the maximum amount of active messages in a
particular MESSAGE file should be. RBBSMail has its own ideas about the
size of a message, so you should take a few precautions.
Configure RBBS-PC to use MESSAGES files that grow as messages are added,
and set the maximum amount of messages to 999. RBBSMail will then
automatically manage the size of the MESSAGES files for you. RBBSMail
will always check the number of free records in any MESSAGES file before
it starts processing that file. If there is not sufficient room left to
process the newly entered message in a MESSAGES file, RBBSMail will not
process the file. If, for some reason, the MESSAGES file is full before
the RBBSMail is done, the MESSAGES file will be expanded to ensure that no
messages are lost.
As there are no restrictions to the size of FIDONET messages, it is
possible that you receive mail with more lines per message than you have
pre-set in RBBS-PC's CONFIG program.
You should periodically review the behaviour of your MESSAGES files. Kim
Wells' MU-PURGE program shows statistics about the amount of used and free
space in your MESSAGES files.
Sometimes RBBSMail just hangs up in the middle of a SCAN or TOSS run.
This is usually caused by a broken link in the MESSAGES file. A possible
reason for having your MESSAGES files messed up is that MU-PURGE choked on
a message that was too big to process. If you run MU-PURGE on a MESSAGES
file with a lot of *big* messages, MU-PURGE will sometimes run out of
memory and abort, leaving a broken chain in the MESSAGES file.
It is therefore HIGHLY advised to set the SIZE parameter in RBBSMAIL.CFG
to a value of 12000 or less.
If the above happens, the most elegant way to recover is:
- Use RBBS-PC's CONFIG program to repair the broken MESSAGES file.
- Use RBBS-PC's CONFIG program to pack the MESSAGES file.
- Start RBBS-PC and kill the first message in the MESSAGES file you
just repaired.
- Decrease the value of the SIZE parameter in RBBSMAIL.CFG.
7.2 Filenames for CONFERENCES
Let's take the TENNIS conference from the above examples. You have a
TENNISM.DEF file that holds all the messages and a TENNISU.DEF file that
holds all users of the TENNIS conference. If you create a file TENNIS.ORG
A word on RBBS-PC MESSAGES files 27
RBBSMail v18.1
in the same directory your TENNISM.DEF and TENNISU.DEF files are in,
RBBSMail will take the FIRST line from this file and use it as the text in
your Origin line.
So, for all conferences or subboards on your system, the naming
conventions should be:
xxxxM.def the Messages file of conference with name 'xxxx'
xxxxU.def the Users file of conference with name 'xxxx'
xxxx.DUP the file containing the IDs of messages already imported in this
conference. You shouldn't bother with this file, RBBSMail
handles it for you.
xxxx.ORG the file containing the text of the Origin line for the
conference with filename 'xxxxM.DEF'
For FIDO style message subdirectory, a file named DUPDATA.DAT in the
subdirectory holds the IDs.
7.3 Filenames for SUBBOARDS
RBBS-PC allows any valid DOS filename for MESSAGE and USERS files in
subboards. By not using the standard RBBS-PC xxxxM.DEF naming convention,
MESSAGES files are not accessible by the [J]oin conference command, which
is exactly what you want for a subboard.
This poses a bit of a problem for RBBSMail, for it has no way of figuring
out the names of MESSAGE and USERS files in subboards, execept maybe
reading the RBBSxPC.DEF files for each conference and/or subboard. Due to
the many changes of the RBBS-PC.DEF file in every new version of RBBS-PC,
this is highly unreliable.
Therefore, RBBSMail uses the following convention for MESSAGE and USERS
files that are not named according to the standard RBBS-PC xxxxM.DEF and
xxxxU.DEF method:
ABCXYZ the MESSAGES file of a subboard (NO extension!)
ABCXYZ.USRthe USERS file of the subboard with ABCXYZ as MESSAGE file (.USR
extension is mandatory!)
ABCXYZ.DUPthe file containing the IDs of messages imported in this
conference. You shouldn't bother with this file, RBBSMail
handles it for you.
ABCXYZ.ORGthe file containing the text for the Origin line for this
subboard.
In short:
If your RBBS-PC MESSAGE and USERS files are named in the form of xxxxM.DEF
with an accompanying xxxxU.DEF file, RBBSMail will strip off the M.DEF,
and ONLY the significant part of the MESSAGES file's filename (i.e. the
conference name) will be used to identify the xxxx.ORG and xxxx.DUP
files.
If your RBBS-PC MESSAGE and USERS files (for subboards) only consist of a
filename with no extension, the whole name of the files will be used to
identify xxxx.ORG and xxxx.DUP files.
A word on RBBS-PC MESSAGES files 28
RBBSMail v18.1
7.4 Filenames for FIDO style subdirs
In a FIDO style message subirectory, all messages are in separate files
with the extension '.MSG" (i.e. message 1 will be 1.MSG). The naming
convention for FIDO style message bases differs somewhat from the above
method of naming files for RBBS-PC conferences and subboards.
To have a separate text for the Origin lines in a FIDO style message
subirectory, simply put a file with the name ORIGIN (no extension) in that
particular subdirectory. This is the equivalent of the xxxx.ORG files
mentioned avbove.
The IDs of imported messages are stored in the subdirectory in a file
named DUPDATA.DAT. It is the equivalent of the xxxx.DUP files mentioned
above.
A word on RBBS-PC MESSAGES files 29
RBBSMail v18.1
8. How to set up your mail
8.1 What you need
To get your mail in and out on the FIDONET, you need a number of other
programs and files. (Assuming you already have RBBS-PC running):
■ Frontend mailer (BinkleyTerm, Dutchie or d'Bridge)
■ oMMM, mOOO or Packer, to pack up outgoing mailbundles
■ ARCA and ARCE or PKARC and PKXARC
■ If you don't want RBBSMail to unpack incoming mailbundles, use
Confmail, QM or whatever appropriate program to unpack incoming
mailbundles.
■ A recent nodelist
■ PARSELST, a program to compile and update your nodelist
■ A mail-editor (Dutched or MSGED) to inspect incoming/outgoing mail is
strongly suggested. It will be a great help getting started.
First, you need to set up the frontend mailer and the schedules. Your
local or regional HOST or HUB has to supply the times when you should call
him to deliver and pick up your mail. There is an extensive chapter about
setting up schedules (or events) and routing in the documentation of your
frontend mailer.
If you want to have control over your schedules from within your batch
files (i.e. outside the scheduler of your mail frontend), you may want to
look at the program WDATIME that is included in this package. WDATIME
enables you to test Month, Date, Time and Day of the Week from within your
batch files.
It is STRONGLY recommended to make arrangements with your HOST or HUB to
have him forward the weekly NODELIST or NODEDIFF files, so your nodelist
will always be up to date. See PARSELST.DOC how to set up an automatic
update of your nodelist.
If your HOST or HUB carries the weekly FIDO newsletter or other
newsletters of interest, ask him to forward it to you. There is a lot of
useful information in some of these regular newsletters.
After you set up your frontend mailer and your schedules, you are ready to
run.
Well, sort of..... While setting up the events and the bulky batch file
you need to run your system plus mailer, you should also stick in some
lines containing the proper RBBSMail commands at the proper places. I'm
afraid you are on your own on this, there is no boilerplate for it. You
should at least run RBBSMail shortly BEFORE your main mail event (usually
the National Mail Hour) and AFTER the NMH. If you run mail outside the
NMH, you can run RBBSMail as often as you may need for other events.
Again, you have to decide on this in agreement with whatever other systems
you exchange mail with.
How to set up your mail 30
RBBSMail v18.1
8.2 A quick overview
1. Run RBBSMail to export new messges from your system.
2. Run your mailpacker (oMMM, MOOO or whatever) with the appropriate
schedules and routings (contact your host for the routing). Your
outgoing mail is now ready to be sent.
3. Have your frontend mailer call all other systems you exchange mail
with, or sit and wait for them to call you.
4. Run RBBSMail import/export the received Echomail.
5. You have now succesfully exchanged Echomail. Congratulations!
Note: If you have both FIDO/OPUS style messages directories AND RBBS-PC
MESSAGES files for your Echomail, you need TWO AREAS.BBS files IF you want
the FIDO style conferences to be processed by another program. For
instance, you need an AREAS.BBS for ConfMail to process mail to/from the
FIDO style subdirectories and an AREAS.BBS for RBBSMail to process mail
to/from the RBBS-PC MESSAGES files. The two files may have different
names or may be located in different subdirectories. You can NOT use the
same AREAS.BBS file for both ConfMail and RBBSMail.
8.3 Enhanced Setup / CRITMON<tm>
With combinations of different RBBSMAIL.CFG, AREAS.BBS and xxxx.ORG files
you can do CRITMON<tm>. That is Creative Renaming In The Middle Of The
Nigth. You can appear to the net as two or more completely different
systems. Or run as one system in several different networks. Or both.
Or send all your outbound Echomail to yourself very night. Or cross-feed
two of your echomail sources with a circular feed. Or receive Echomail as
123/1 and send the whole bunch back to your host as 789/2, thus making a
lot of "friends".
Don't rush to your keyboard to do CRITMON<tm> right away. Remember,
Personal Computers can be used Personally, programmed Personally and you
can Personally screw the thing up beyond belief. Like me, you are likely
to do the latter.....
Sit down with a big sheet of paper, a pencil and a pencil eraser. Setup
an overview of what you want your system to do and where you send mail
to. Figure out the setup of your config files and your schedule(s) of
events. Then, make ONE setup and test it. up your system for ONE of the
alternatives and test it. With another sheet of paper, setup the other
alternatives, and test them one by one. In any case, don't change more
than one thing at a time in your setup. FUBAR is the word!
RBBSMail will (in most cases) do faithfully what you want, even with the
craziest setup. If it doesn't do what you want, (and even if it does) you
have yourself to thank for it.
Since most of the address translation is done completely transparent by
RBBSMail, you usually need just ONE setup.
How to set up your mail 31
RBBSMail v18.1
8.4 Cross-zone echomail / CRITMON<tm>
If you are a node in more than one Zone, RBBSMAIL will be quite creative
when CRITMONning. For instance, you run as 2:512/10 in FIDONET Zone 2 and
as 8:998/1 in RBBSNet. You have will have addresses in RBBSMAIL.CFG
listed as:
Address 2:512/10
Address 2:2/508
Address 8:998/1
and a line in your AREAS.BBS lik this one:
C:\RBBS\CHATM.DEF CHATTER 2:512/1 2:9999/1 8:998/10
Now, RBBSMail will export messages to 2:512/1 (your FIDONET host), to
2:9999/1 (one of your points) and to 8:998/1 (your RBBSNet host).
But..... the messages sent to 2:512/1 and 2:9999/1 will have an
originating address of 2:512/10, and the messages to 8:998/10 will have an
origin address of 8:998/1 in the binary message hader.
Messages that were entered locally on your system will also have variable
addresses in the * Origin: line, depending on the destination address.
However, the MSGID tag will ALWAYS have your primary address. MSGID needs
to be unique for every message and it is not a good idea to use two or
more different 'unique' IDs.
Same goes for the PATH line, which will ALWAYS carry your primary
address.
In other words, RBBSMail adjusts the originating address of outgoing
echomail messages to match the address you use in the destination zone.
This way, secure echomail distribution accross zones will be possible and
you don't have to bother with running different setups for sending
echomail to different zones.
Please note that RBBSMail will, by default, only put your PRIMARY address
in the SEEN-BY lines. If you exchange mail with other systems using one
of your alternate adresses, you must either use the -AKA command line
switch to tell RBBSMail to put one or more of your alternate addresses in
the SEEN-BY line or configure a GATE phrase for those destination
addresses.
RBBSMail uses the same naming convention for outbound subdirectories as
BinkleyTerm and oMMM does. If you have set your HOLD subdir like in the
examples above, RBBSMail will write outbound echomail addressed to any
node in your own zone (in this case, zone 2) to the subdirectory
C:\BT\HOLD.
For each additional destination zone, RBBSMail needs a separate
directory. The additional directories simply get an extension (Yeah, I
know that subdirectory names aren't supposed to have extensions).
The 3-digit hexadecimal representation of the destination zone number is
used as extension. Following the above exapmles, all outbound mail
addressed to Zone 4 is written to the subdirectory C:\BT\HOLD.004,
How to set up your mail 32
RBBSMail v18.1
outbound stuff for zone 30 ends up in a subdirectory named C:\BT\HOLD.01E
and mail for zone 69 will be written the C:\BT\HOLD.045 subdirectory.
If you run RBBSMail in combination with BinkleyTerm and/or oMMM, you
probably already have these additional subdirectories and they will
automatically be used by RBBSMail. If they aren't there, RBBSMail will
create additional subdirectories whenever it needs them.
If you run RBBSMail with another frontend mailer than BinkleyTerm, you
probably need to tell your mailer and/or mailpacker that it should look in
the additional subdirectories for outbound mail to other zones. There's
no need to bother about this if you use the -FA command line switch. The
FileAttach messages created by RBBSMail will alwys end up in your NETmail
directory, with the proper drive, path and filename for the attached
mailbundle.
8.5 Network Gateway Systems
The Public Amateur Computer Network, commonly known as FIDONET, used to be
the only system of linked bulletin boards in the world. For the last few
years, new FIDO compatible networks have popped up. There now are
AlterNet, Turbo Data Net and RBBSNet, to name a few.
These networks are completely independent structures, but lately people
started exchanging Echomail between these networks. This poses some
political and operational problems. Politics should be left to
politicians, so I will only deal with the operational stuff.
Let me give an example to clarify the problems. Suppose a system in
FIDONET Zone 2 wants to exchange Echomail with a system in the RBBSNet
(which uses zone 8 for practical purposes) and pass it on to other systems
in the FIDONET. All Echomail received from the RBBSNet systems will list
an address in the Origin line that is not a valid FIDONET address.
Just passing this netmail through will probably get a FIDONET coordinator
up the wall, for FIDONET does not like to carry around messages with
invalid (non-FIDONET) addresses. As the RBBSNet system will not be in the
FIDONET NODELIST with his RBBSNet node number, his RBBSNet nodenumber will
be invalid in FIDONET, so we need to do something about that.
For instance, FIDO 2:2/508.0 will serve as the inbound Network Gateway for
Echomail from RBBSNet (which uses fake zone number 8) to FIDO zone 2. All
(or most) Echomail received from RBBSNet will list zone 8 addresses in the
Origin lines. To fullfill the above FIDONET requirements, all messages
that are send out by 2:2/508.0 to other FIDONET systems should have a
valid Origin address in the Origin line. RBBSMail will take care of this
in a simple manner.
The INDOMAIN phrase in RBBSMAIL.CFG should list the (fake) ZONE number of
the other network for which your system is the Network Gateway, plus the
Origin line to be added to messages from the other network. On 2:2/508.0,
the INDOMAIN statement looks like this:
INDOMAIN 8 RBBSNetwork Gateway to Europe (2:2/508.0)
How to set up your mail 33
RBBSMail v18.1
A practical example: A message entered on RBBSNet 8:926/1.0 will have that
address listed in the Origin line. When 2:2/508.0 receives this messages
and sends it out to a system in a zone OTHER than zone 8, the Origin line
will be zapped and an extra Origin line "RBBSNetwork Gateway to Europe
(2:2/508.0)" will be added to the messages. This fullfills the FIDONET
requirement of valid addresses.
The conversion will ONLY take place for messages that originate from a
system in the zone listed in the "INDOMAIN" phrase AND if those messages
are sent to a system that is not in that zone. Messages that stay within
the same zone or messages that originate from other zones will be left
untouched.
Only one INDOMAIN network gateway can be defined (there ain't no such
thing as an outdomain). One should exercise great care in setting up
systems like this. Contact your network or zone coordinator, agree on
terms and conditions for operating the Network Gateway. Be sure to inform
other systems about the proper routing for mail that has to pass through
the network gateway.
The above method is rather simple and somewhat crude, but it has been in
operation at 2:2/508 since September 1988 without problems.
8.6 Error determination
Sometimes it looks as if you just can't get it right. If you encounter
problems with RBBSMail, step thru the following procedure to diagnose the
situation.
1. RTFM.
2. Check the configuration files for typos, incorrect drive, path or
filenames. Check contents of AREAS.BBS. Change if needed.
3. RTFM again.
4. Check the command line for proper switches. Change if needed.
5. Relax, have a cup of coffee and let the situation soak in for a while
6. Run the program again.
7. If the symptoms change, repeat the above steps till the error
'magically' disappears.
8. If the above steps fail, erase RBBSMail.LOG.
9. Run RBBSMail in the failing situation.
10. Send me a CRASHmail message with the problem properly described.
File-attach a copy of your setup files and a LOG file that shows the
problem. Feel free to include any other relevant information, like
type and version number of hardware and software you use, filesizes,
AREAS.BBS and BINKLEY.CFG. You may wish to include examples of
failing messages or mailbundles.
11. Poll my system after a few days to see if there's a reply for you. If
you have a real problem, and I'm not on vacation, there will be a
reply (and hopefully a fix) waiting.
12. If there's no reply and I'm not on vacation, RTFM and repeat the above
steps.
13. Flames will never be dignified with an answer.
How to set up your mail 34
RBBSMail v18.1
8.7 Other stuff
I'm sure you will have a lot of questions about Echomail. It is a strange
sort of animal to RBBS-PC sysops. But, don't fear! Echomail can be fun
and can be a great enhancement to your system. If, at first, you don't
understand what Echomail is all about, talk to a local OPUS or FIDO sysop
or to the sysop of the host in your local network. Sysops are strange
birds, but very helpful and usually eager to show you around. The moment
you have your Echomail running you'll see the benefits of it.
If you decide to hook up your RBBS-PC system to the world of FIDONET, you
also may wish to take part in several RBBS-PC related Echomail
conferences. In the USA, contact your local host system. In Europe,
contact me by sending me a netmail message, and start polling for mail a
few days later.
And there are several Echomail conferences about the frontend mailers
BINKLEY (for BinkleyTerm), WINDMILL (for Dutchie) and FD (for FrontDoor).
If a local or regional HOST or HUB carries a conference on the mail
frontend you use, make arrangements to get the echo. It will be of great
help to you.
How to set up your mail 35
RBBSMail v18.1
9. The RBBSNet
Several RBBS-PC sysops have started a RBBSNet, separate from FIDONET.
Currently, there are a bunch of FIDO compatible networks in operation:
FIDONET, EggNet, The People's Net, AlterNet, TuboDatanet and GT-Net. I'm
part of both FIDONET and RBBSNet, and my system is the European gateway
for RBBSNet (node 8:998/1.0 in the RBBSNet). For more info on the
RBBSNet, Contact Rod Bowman of the PC-Spectrum RBBS in Alta Loma, CA at
(714) 945-2612. Rod has put an enormous amount of work in setting up the
RBBSNet. I sure hope it will all work out.
The RBBSNet 36
RBBSMail v18.1
10. Future enhancements
10.1 Planned for new releases
In order of priority:
1. Addition of Smart Zone and Point remapping
2. Addition of AutoEcho/AreaFix capabilities.
3. Addition of mailpacker/router (currently being written).
4. Full NETmail capability, but this is waiting for some major changes in
RBBS-PC.
If you have any comments, suggestions for enhancements or you have found
something in RBBSMail that doesn't work the way it should, feel free to
contact me via Bamestra RBBS. See the title page of this document for the
node number and phonenumbers. You may also leave a message in the RBBS-PC
or RBBSMAIL_PACK Echomail conferences.
10.2 Comments & Suggestions
If you have comments on the workings of RBBSMail, suggestions for new
features, improvements or bug reports, feel free to send a NETmail message
to Sysop at FIDO 2:512/10.0 (RBBSNet 8:998/1.0) or a written letter to the
postal address listed on the title page.
Future enhancements 37
RBBSMail v18.1
Appendix A. Changes to RBBS-PC
There is a conflict between RBBSMail's way of flagging messages that are
processed and "repair message file" option 185 in RBBS-PC's CONFIG
program. RBBSMail changes the ":" (colon) in the datefield of the message
header to a "." (dot) to flag a message. CONFIG's option 185 will choke
on this, because it uses that same ":" to scan for valid message headers.
This will result in mixed-up message numbering. To circumvent this
conflict, either do not use CONFIG option 185 (you don't normally need
that option), or remove the following line from linenumber 50580 of module
CONFIG.BAS:
AND MID$(MESSAGE.RECORD$,64,1) = ":" _
This line appears TWICE in linenumber 50580.
Appendix A. Changes to RBBS-PC 38
RBBSMail v18.1
Appendix B. Update history
January 17, 1992 - Initial release of RBBSMail v18.0
■ Complete rewrite of RBBSMail in C.
■ Maintenance moved to a separate program RBBSMNT.
■ Buggy Zone and Point remapper removed.
February 28, 1992 - release of RBBSMail v18.1
■ Added ExportComments configuration phrase.
■ Improved errorchecking for grunged bunldes.
■ Changed order in which ARCmail bundles are processed.
■ Fixed bug that incorrectly reported inconsistent header records in
messages files.
■ Fixed bug that dumped copies of PASSTHRU messages in netmail area.
■ Fixed bug that incorrectly set message attributes on RTS messages.
■ Fixed bug in ARCmail address parsing (ARCto, ZIPto et al).
Appendix B. Update history 39
RBBSMail v18.1
Table of Contents
1. WARNING! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. What is RBBSMail . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Software Requirements . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.4 Related Documents . . . . . . . . . . . . . . . . . . . . . . . . 4
2.5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Legal Stuff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Copyrights & License . . . . . . . . . . . . . . . . . . . . . . 5
3.2 NO WARRANTY . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 NO MONEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 The RBBS commitment . . . . . . . . . . . . . . . . . . . . . . . 8
4. Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1 Configuring RBBSMail . . . . . . . . . . . . . . . . . . . . . . 9
4.2 Valid phrases for RBBSMAIL.CFG . . . . . . . . . . . . . . . . . 9
4.2.1 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2 ARCto, ARJto, PAKto, LHAto, ZIPto, ZOOto. . . . . . . . . 10
4.2.3 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.4 DupSize . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.5 ExportComments . . . . . . . . . . . . . . . . . . . . . . 11
4.2.6 Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.7 Hold . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.8 ImportDate . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.9 Indomain . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.10 KillNull . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.11 LogLevel . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.12 MaxOut . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.13 NetFile . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.14 NoRts . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.15 NoStinkingKludgeLines . . . . . . . . . . . . . . . . . . 13
4.2.16 OpusDate . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.17 Pack . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.18 PrivateNet . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.19 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.20 Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.21 SecureMail . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.22 StatusLog . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.23 StripSeen . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.24 SysAlias . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.25 Sysop . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.26 Reading BINKLEY.CFG . . . . . . . . . . . . . . . . . . . 16
4.2.27 Example of a RBBSMAIL.CFG file . . . . . . . . . . . . . . 17
4.2.28 Example of an AREAS.BBS file . . . . . . . . . . . . . . . 18
Table of Contents 40
RBBSMail v18.1
5. Running RBBSMail . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1 Commandline options . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 -A <areasbbsfile> . . . . . . . . . . . . . . . . . . . . . 21
5.1.2 -AKA # . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.3 -BM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.4 -C <configfile> . . . . . . . . . . . . . . . . . . . . . . 22
5.1.5 -FA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.6 -H . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.7 -I . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.8 -KN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.9 -OB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.10 -OF . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.11 -OP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.12 -P . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.13 -S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1.14 -T . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1.15 -X . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6. A word on echomail distribution . . . . . . . . . . . . . . . . . . 25
7. A word on RBBS-PC MESSAGES files . . . . . . . . . . . . . . . . . 27
7.1 Filesizes . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.2 Filenames for CONFERENCES . . . . . . . . . . . . . . . . . . . 27
7.3 Filenames for SUBBOARDS . . . . . . . . . . . . . . . . . . . . 28
7.4 Filenames for FIDO style subdirs . . . . . . . . . . . . . . . 29
8. How to set up your mail . . . . . . . . . . . . . . . . . . . . . . 30
8.1 What you need . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.2 A quick overview . . . . . . . . . . . . . . . . . . . . . . . 31
8.3 Enhanced Setup / CRITMON<tm> . . . . . . . . . . . . . . . . . 31
8.4 Cross-zone echomail / CRITMON<tm> . . . . . . . . . . . . . . . 32
8.5 Network Gateway Systems . . . . . . . . . . . . . . . . . . . . 33
8.6 Error determination . . . . . . . . . . . . . . . . . . . . . . 34
8.7 Other stuff . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. The RBBSNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Future enhancements . . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Planned for new releases . . . . . . . . . . . . . . . . . . . 37
10.2 Comments & Suggestions . . . . . . . . . . . . . . . . . . . . 37
Appendix A. Changes to RBBS-PC . . . . . . . . . . . . . . . . . . . . 38
Appendix B. Update history . . . . . . . . . . . . . . . . . . . . . . 39
Table of Contents 41